This present invention relates to generating data for volume rendering. Direct volume rendering includes several different techniques, roughly classified as image-based (backward projective), e.g., ray-casting, and object-based (forward projective), e.g., cell projection, shear-warp, splatting, or texture-based algorithms. The common theme is integration along viewing lines of data (e.g., RGBα values) within a volume for each pixel of a three dimensional representation.
Direct volume rendering is provided for medical images, such acquired with Magnetic Resonance (MR), Computed Tomography (CT), Positron Emission Tomography (PET), or any other medical tomographic scanner capable of producing a series of images in a grid-like array. Recent technological advances in the field of tomographic imaging have greatly improved the spatial resolution and speed of data acquisition, resulting in the production of very large datasets composed of hundreds, and even thousands of images. For example, it is possible to rapidly generate a sequence of 1024 images using the Siemens SOMATOM VolumeZoom™ CT scanner, with each image being composed of a grid of 512×512 picture elements, resulting in a three-dimensional volume of 512×512×1024 volume elements (over 268 million data values). In the Oil and Gas industry, seismic data measurements are also stored in very large three-dimensional volumes, with as many as 2048×2048×2048 grid elements (over 8.5 billion data values).
Direct volume rendering may require random access to the data values of the three-dimensional array, and therefore the entire array is stored in the computer's RAM or graphics processing unit (GPU) memory. Such an enormous amount of data is often larger than the random-access memory (RAM) storage available on modern computers. In order to compute direct volume renderings of very large volumes, a costly apparatus with very large amounts of RAM is used.
When using a 32-bit CPU, the size of array used for direct volume rendering is limited to the maximum number of data elements addressable by the CPU. Some three-dimensional arrays can be so large that their size exceeds the memory addressing capability of 32-bit central processing units (CPU) found in many personal computers and graphic workstations, which is limited to a maximum of 4.2 billion data elements.
Volume rendering methods may also require resampling the volume data into a uniform Cartesian grid. The images all have the same resolution and dimensions, and the distance between adjacent images is constant for the complete set of volume data.
The data for the volume can be stored in a single 3D texture, and three texture coordinates from the vertices of the slices are interpolated over the inside of the slice polygons. The three texture coordinates are employed during rasterization for fetching filtered pixels from the 3D texture map. Depending on the size of the 3D texture, cache performance of the CPU or GPU will suffer. It is also possible to decompose the volume into several smaller 3D textures (bricks) to increase cache performance. However, to ensure contiguous interpolation between bricks, the volume data has to be replicated on the boundaries of bricks. As caches in CPUs and GPUs are relatively small, the volume data is broken down into a large number of bricks to ensure optimal cache performance. A lot of volume data is replicated on the brick boundaries, which is not a practical solution for large volume data. Additionally, the data must be rearranged in memory from the original representation as a stack of slices.
An alternative approach is to store volume data as a number of two-dimensional images (2D textures). A single image of the volume data is rather small compared to the complete volume. Rendering a single two-dimensional texture at a time yields good cache performance. However, this approach requires three copies of the volume data to be stored in memory, where each copy is oriented with one of the three main axes of the volume data. The copy of the volume data with a main axis most perpendicular to the viewer's line of sight is used for rendering to ensure good memory access patterns and cache coherency.